Hi all!
I'm new to the Drupal UX community, but not new to Drupal or User Experience Design. (I've added some info to my drupal.org profile for those interested in reading more...) I just finished speaking with yoroy about diving into Drupal UX work and the topic of Account Management came up. I mentioned how much it annoyed me and, lo and behold, it turns out that it's a pretty common pain point around here. So, I thought I'd kickoff my inaugural journey into doing UX with the Drupal Community with a discussion about Drupal's Sign In, Registration, and Account Management interactions.
I'd like to kick off the project with a general discussion around use cases, pain points, and design patterns and reference points. From there, I'll kick off a round of documentation and wireframes. From here, we'll identify which functionality and updates should go into Core and which might be better suited for Snowman and modules.
Just to be clear, I'd like to identify general issues with the Drupal Accounts. I'm not suggesting that all these things get integrated into Drupal Core. Rather, that I would like to see these issues addressed in some way. And, as we progress through the process, we'll determine how each feature and update should be handled.
I'll start with my pain points, use cases, and design references:
Pain Points
What are the really annoying things about the current system that we should address in this update? Here are mine:
- Users can't log in using their email address.
- Can we use email address as username? At least make that a configuration option.
- The forms are too long. I mean even when they're short, they are long. There's a lot of help text that seems unnecessary or could be better hidden. For example, in the form I'm using right now,
- What's with all the fieldgroups? It takes up a lot of space without adding value and often there's only one form field in the fieldgroup.
- What's with the tabbed UI? Tabs for Sign in, Forgot Password, and Register? Those are hard to miss.
- I'd like it easy to configure between having a layer for register and sign in or taking people to a specific page for registration and signing in.
- Are Facebook, Twitter, and Google Plus sign ins integrated into Core? If not, why not?
- Smarter form fields. I think this one is deeper than Account Management. Things like the Better Country Selector.
- Smarter assumptions around the basic account creation form. The assumptions around the defaults could be better.
- Ignore caps in usernames. McRick and mcrick and mcRick should all be the same person.
- Viewing versus editing. Why, when I go to the Account Settings screen, am I viewing my profile instead of editing it? The view/edit paradigm makes little sense here.
- Limits on password should be configurable (spaces should be allowed and passphrases encouraged)
- Better display of errors
- Built-in JavaScript to catch errors before user submits
- AJAX hooks to do real-time look ups on email address and username
Please add to this list -- and call me to the mat on any of these you think are good parts of the current design!
Use Cases
I'm just looking for some general thoughts on the different use cases you've seen the Sign In, Registration, and Account Management interactions employed. No need to flesh them out in detail here. I'd like enough information so I understand the scope of use. Also, please address all the use cases -- not just use cases that have, historically, required some customization or module to implement. IOW, functionality on this list may already exist and that's okay as I'd really like to think about these things from the ground up.
I'll start out:
- Stakeholder wants to remove option for visitors to register
- Visitor needs to use functionality that is inaccessible to them until they register or sign in.
- Visitor wants to register using federated login (Twitter, Facebook, or Google Plus)
- Visitor or User wants to view another users profile
- User wants to set their profile to private so other people can't see it
- User wants to change their email address, password, picture, or other information on their profile
- User wants to change critical information about their account (credit card) and should re-enter their password to do so
- Internal staff needs to register for the site so they can use the system's admin functionality.
- Admin adds someone to the system who then needs to complete registration so they can use the system.
- Admin adds someone to the system and sends the person their login and password.
- Admin needs to initiate a reset password request for a specific user
- Admin needs to change a users role
** Includes bulk adding/changing roles - Admin needs to create a new role
- System assigns roles based on information provided during account creation.
** This may need to be reviewed and approved by an admin - Admin needs to edit users account information
- Admin needs to delete users account information
** Bulk delete, too - Stakeholder wants the option of adding new fields to a users profile
- Stakeholder wants the option of connecting a users Facebook, Twitter, or Google Plus account to a visitors profile
Please add to this list as you see fit. Much of this functionality may already exist. And that's fine. I really want to start from the ground up to see what this system should really look like.
Design Patterns and Reference Points
What are some good current registration, sign in, and account management systems that we can use as a reference point?
- Signing in or registering via layer (Reddit - try to upvote without being logged in)
- Sign out buried under menu (Facebook and Twitter)
- Simple register and sign in form exposed on homepage (Facebook and Twitter)
- Simple Registration Form (Twitter)
- Call-to-action to register replaces functionality (replying or upvoting is replaced with call-to-action) versus trying to do something that requires registration triggers registration process
- Combine registration and sign in form (Amazon)
I'm sure there are a lot more design references out there. Whether they are good or not, let's collect them here for future reference.
Looking forward to working in the Drupal UX community! Definitely hope y'all don't mind if I dive in head first.
Full documentation will be here in this gDoc:
https://docs.google.com/a/bluesparklabs.com/document/d/1ePkvASia99oYjaLn...
It's open for all to edit.
Thanks!
Rick
Comments
Product vs Platform
Some of the ideas could be implemented as-is in core, but some of them make assumptions of what the default use case is for the website and step into the ye-olde Platform vs Product discussion. Drupal won't include support for authentication via 3rd party services because each main release is supported for several years, whereas APIs tend to change much more frequently than that, so that's something best left to 3rd parties. Perhaps you should also look into the Snowman project which aims to define & build a general-purpose starter distribution that could benefit from some of these ideas?
Thanks for the pointers to
Thanks for the pointers to the Platform vs. Product discussion. I'll be reading that next. That does make a lot of sense to separate the 3rd party APIs from Core Drupal, though.
You have any other suggestions for how you'd like to see the Drupal Account system updated?
Thanks!
Rick
UX Director, Bluespark
Welcome!
This is such a well documented train of thought. I understand your concerns. I suffer from the same pain.
I am looking forward to this effort :)
Dharmesh Mistry
UX Researcher | Acquia,Inc.
Hi Dhamesh, Great to hear
Hi Dhamesh,
Great to hear from you! Would love to hear any of the pain points that you're having to make sure we're covering as much as possible in this effort.
Thanks!
Rick
UX Director, Bluespark
Thanks Rick! (more later, i'm
Thanks Rick! (more later, i'm out of town for the weekend) The distinction Damien makes is an important one to get a feel for (the lines are blurry). Great to see you dive in head first, thanks for coming through so quickly.
Thanks for all the great
Thanks for all the great thoughts and encouragement! Definitely looking forward to getting your feedback on how to improve Drupal Accounts!
-Rick
UX Director, Bluespark
Much of this functionality
Much of this functionality exists already and is intentionally separated from core and maintained through modules, so it is down the set up of any given site.
I do think there is room for improvement in Drupal core, but that the real place for perfecting a base set up is through Snowman.
Hi Graeme! Great points all.
Hi Graeme! Great points all. I'm really still getting my legs under me and will be digging into the difference in Core and Snowman and the philosophy behind Product vs. Platform. Damien provided some very helpful links.
In the meantime, though, it would be helpful to get some perspective on the different use cases for Drupal and see if we can narrow in on functionality needed to support each use case. Possibly, from there, determine if what would be better done in Core or Snowman -- or even something else. I'll update my original post (if I can) to address this issue.
Thanks for the direction. Do you have any specific concerns that you'd like to see addressed in Drupal Accounts? (Either in Core or Snowman).
Thanks!
Rick
UX Director, Bluespark
Hey Rick, Good stuff. Nice to
Hey Rick,
Good stuff. Nice to see someone grabbing the bull by the horns.
The way I hope we see this going in the future is by having a multitude of Install Profiles that sit somewhere between Core and Contrib. Maybe making a list of all the potential use cases is a good place to start here.
Definitely think we'll be
Definitely think we'll be creating different install profiles or versions for different distros. For now, though, I want to focus on getting everything and the kitchen sink in there -- and then think about segmenting things out. IOW, I don't want to get bogged down with what should go into core and what should be part of a distro at this stage of the process.
UX Director, Bluespark
Lets not throw in the install
Lets not throw in the install profiles argument too soon though. I'm sure there's a better core default to be had than the crap setup we get out of the box now.
Completely agree. I want to
Completely agree. I want to design a great UX and then determine how it needs to get chopped up -- and then regroup as needed.
UX Director, Bluespark
Another monkey wrench
I have 3 sites no one needs to ever sign into but the admin. How about a way to turn off registration? The core is still lacking basic features. Before Drupal I could easily do this in HTML and Java.
Head Dragon Kid Stevens
Of Web-DrupalDesign .com
This makes a lot of sense.
This makes a lot of sense. Sounds like this would just be a matter of hiding the registration and sign in field from most people, right? After all, you still want people to be able to sign in for admin controls? If I am oversimplifying, can you elaborate on any other difficulties you're having?
UX Director, Bluespark
It is not really difficulty.
It is not really difficulty. I just don't want to write the underlying php. If the user core module just had a login and registration show checkbox that would simplify it. With a forgot password function the login and a 3 password failure that would be even better. Oh and on each failure an email to the primary admin.
Head Dragon Kid Stevens
Of Web-DrupalDesign .com
Okay. Just making sure that I
Okay. Just making sure that I wasn't over-simplifying the issue.
UX Director, Bluespark
Again
I'll drop this after this one comment, but I wanted to make sure headdragon knew that you can (without writing php), turn off account user account registration, and you will not be prompted to register anywhere on a drupal site. There is a forgot password function on the login screen as well. If you don't have these configured on your drupal site, I'd recommend going to the support channels rather than this forum to get help on configuring user account registration.
The 3 password failure is not there, nor is an email every time a login failure happens.
And
This can be done today with core settings. I think the question will in fact be how to package the profiles with the right settings in a way that makes sense to those selecting it. Right now the two settings that control this behavior are not co-located. (one is a theme issue and another a user account settings issue).
You'll need to be careful about tackling the use cases at the right granularity here or situations like this will make this too big to do anything about.
Thanks for the feedback!
Thanks for the feedback!
UX Director, Bluespark
IRC meeting notes
Full meeting notes here: http://groups.drupal.org/node/204763#comment-674378
Rick Cecil started a big rundown of pain points and use cases for the account registration and user profile UX. We discussed how to approach this interesting design problem and come up with a plan that will help get this chopped up into actionable issues. For some points, issues already exist (look'm up, post them in here).
The general idea: evaluate the account management process and propose a holistic design goal and approach for how to get there, starting with the registration workflow. We'll want to take the main (core) scenarios and map these out in the screens (or touch points) that people encounter when they go through these scenarios.
Also: https://twitter.com/#!/BarisW/status/161586606258651136 :)
Thanks for all the support,
Thanks for all the support, yoroy!
(And, ack! Those tabs are almost the whole reason that I got started down this path in the first place!)
UX Director, Bluespark
Update: First Pass at Visitor Scenarios
I have completed first pass at registration scenarios in the Google Doc:
https://docs.google.com/a/bluesparklabs.com/document/d/1ePkvASia99oYjaLn...
I've broken down the user roles into Visitor (people who need to sign in or register), User (people who are signed in), and Admin (people who have control over other accounts). I have some of the legwork completed on Visitor registration and could use feedback. More to come throughout the week.
UX Director, Bluespark
https://twitter.com/#!/fiona_
https://twitter.com/#!/fiona_doyle/status/170450775875649536
and
https://twitter.com/#!/fiona_doyle/status/170462074185596928
As most might know, Login
As most might know, Login Toboggan provides enhancements to the registration experience.
One of those is the ability to validate emails when the user is registering with "set password on registration" enabled and place that user on an intermediate role until that happens. Think I didn't see something like this listed above.
There's a core issue by the maintainer of that module to add this feature here: http://drupal.org/node/783184
Maybe we should come up with a tag to track login-related issues ?
Can i chip in [META] Refactor
Can i chip in [META] Refactor account workflow (and config) http://drupal.org/node/1837054 (as a startingpoint)
By the way: http://drupal.org/project/user_registrationpassword as a partial alternative for Login Toboggan + this sandbox for passive e-mail confirmation works pretty good already.
And User Registration Password also has a D8 patch available > http://drupal.org/node/115801